Structured data conforms to a type definition. For example, a type definition for a “person” type may define distinct attributes such as “name,” “birthdate,” “height,” “weight,” and “gender.” Each “instance” of a particular type comprises a separate value for each of the attributes defined by the particular type. For example, an instance of the “person” type might comprise values such as “Fred Brown,” “Jan. 1, 1980,” “72 inches,” “240 pounds,” and “male.” Each attribute is also of a type. For example, the “name” attribute might be of a “string” type, the “birthdate” attribute might be of “date” type, and the “gender” attribute might be of an “enumerated” type. Structured data might comprise multiple different instances of the same type.
Different approaches may be used to store structured data into a database. One such approach is called “conventional path loading.” According to conventional path loading, a loader application parses structured data that comprises one or more instances of a type. Values within the structured data correspond to attributes of the type. The loader application generates Structured Query Language (SQL) commands, such as INSERT commands, that, when executed by a database server, cause the database server to insert the values into corresponding columns of a database table. Unfortunately, due to its heavy use of the SQL engine, conventional path loading often suffers in terms of performance and memory consumption.
Another approach for storing structured data into a database is called “direct path loading.” Through direct path loading, values within structured data are stored directly into a database without causing the SQL engine to load each row of data. By consulting a control file that is associated with the structured data, a loader application with direct loading functionality can determine the types to which instances within the structured data conform. If the structures of the types are defined to the loader application, then, based on those structures, the loader application can create an array that comprises elements that correspond to the types' attributes. The loader application can populate each attribute's corresponding element with values that correspond to that attribute. Once the array is populated, the loader application can convert the array into a data stream that conforms to the format of a database's data blocks. The loader application then can stream the data to a database server, which can write the data directly into one or more data blocks in the database. Direct path loading exhibits performance superior to that of conventional path loading.
Some types indicated by a control file may be standard types that are defined to a loader application. A scalar type is an example of such a standard type. The loader application has information about the characteristics of a scalar type, such as the maximum storage size of a scalar type. With this information, the loader application can generate the data stream as described above.
However, some types indicated by a control file might not be among the types that are defined to the loader application. A type indicated by a control file might have a structure that is defined only to a program that implements that type. Although the type might comprise attributes that are of standard types, the control file and the loader application might lack any information about the number or types of such attributes.
Without such information, the loader application cannot generate or populate an array that comprises a separate element for each such attribute. The loader application does not possess sufficient information to map values that correspond to such attributes to corresponding columns of a table in a relational database. Consequently, there is no effective way for the loader application to store instances of such a type in a database using the direct path loading approach.
Types that are not defined to a loader application are called “opaque types” relative to the loader application, because the internal structure of such types is unknown to the loader application. The internal structure of an opaque type, including the number and types of attributes of the opaque type, often is known only to a program that implements the opaque type. Such a program may be external to both the loader application and the database server.
It may not be practical to modify a loader application every time that a new opaque type is introduced, so that the new type is known and supported by the loader application. Additionally, the structures of some existing types may change as time passes. It may be impractical to modify a loader application every time that the structure of an existing type changes.
At present, loader applications are unable to use the direct path loading approach to store instances of opaque types other than as large objects (LOBs). Because the direct path loading approach exhibits performance superior to that of the conventional path loading approach, a technique is needed for storing instances of opaque types according to the direct path loading approach.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.